内核使用kmalloc和kfree函数分别分配和释放内存块。这两个函数的语法类似于libc 用户空间库中的两个姐妹调用malloc和。有关和 的更多详细信息，请参阅Linux 设备驱动程序(O'Reilly)。freekmallockfree

The kernel uses the kmalloc and kfree functions to allocate and free a memory block, respectively. The syntax of those two functions is similar to that of the two sister calls, malloc and free, from the libc user-space library. For more details on kmalloc and kfree, please refer to Linux Device Drivers (O'Reilly).

内核组件分配相同数据结构类型的多个实例是很常见的。当分配和释放预计经常发生时，相关的内核组件初始化例程（例如，fib_hash_init用于路由表）通常会分配一个特殊的内存缓存来用于分配。当内存块被释放时，它实际上返回到分配它的同一缓存中。

It is common for a kernel component to allocate several instances of the same data structure type. When allocation and deallocation are expected to happen often, the associated kernel component initialization routine (for example, fib_hash_init for the routing table) usually allocates a special memory cache that will be used for the allocations. When a memory block is freed, it is actually returned to the same cache from which it was allocated.

内核为其维护专用内存缓存的网络数据结构的一些示例 包括：

Some examples of network data structures for which the kernel maintains dedicated memory caches include:

以下是用于处理内存缓存的关键内核函数：

Here are the key kernel functions used to deal with memory caches:

可以从给定缓存（如果存在）分配的实例数量的限制通常由 周围的包装器强制执行，有时可以使用/prockmem_cache_alloc中的参数进行配置 。

The limit on the number of instances that can be allocated from a given cache (when present) is usually enforced by the wrappers around kmem_cache_alloc, and are sometimes configurable with a parameter in /proc.

有关如何实现内存缓存以及它们如何与slab分配器接口的更多详细信息，请参阅了解Linux内核 （O'Reilly）。

For more details on how memory caches are implemented and how they interface to the slab allocator, please refer to Understanding the Linux Kernel (O'Reilly).

使用缓存来提高性能是很常见的。在网络代码中，有用于L3到L2映射的缓存（例如IPv4使用的ARP缓存），用于路由表缓存等。

It is pretty common to use a cache to increase performance. In the networking code, there are caches for L3-to-L2 mappings (such as the ARP cache used by IPv4), for the routing table cache, etc.

缓存查找例程通常采用一个输入参数，该参数表示缓存未命中是否应该创建新元素并将其添加到缓存中。其他查找例程只是简单地添加缺失的元素。

Cache lookup routines often take an input parameter that says whether a cache miss should or should not create a new element and add it to the cache. Other lookup routines simply add missing elements all the time.

缓存通常使用哈希表来实现 。内核提供了一组数据类型，例如单向和双向列表，可以用作简单哈希表的构建块。

Caches are often implemented with hash tables . The kernel provides a set of data types, such as one-way and bidirectional lists, that can be used as building blocks for simple hash tables.

处理哈希为相同值的输入的标准方法是将它们放入列表中。遍历此列表比使用哈希键进行查找所需的时间要长得多。因此，最小化哈希为相同值的输入数量始终很重要。

The standard way to handle inputs that hash to the same value is to put them in a list. Traversing this list takes substantially longer than using the hash key to do a lookup. Therefore, it is always important to minimize the number of inputs that hash to the same value.

当哈希表上的查找时间（无论是否使用缓存）对于所有者子系统来说是一个关键参数时，它可能会实现一种机制来增加哈希表的大小，以便减少冲突列表的平均长度并且平均查找时间得到改善。有关示例，请参阅第 34 章中的“动态调整每个网络掩码哈希表的大小”部分。

When the lookup time on a hash table (whether it uses a cache or not) is a critical parameter for the owner subsystem, it may implement a mechanism to increase the size of the hash table so that the average length of the collision lists goes down and the average lookup time improves. See the section "Dynamic resizing of per-netmask hash tables" in Chapter 34 for an example.

您还可能会发现子系统（例如相邻层）将随机组件（定期更改）添加到用于在缓存存储桶中分配元素的密钥。这用于减少旨在将哈希表的元素集中到单个存储桶中的拒绝服务 (DoS) 攻击的损害。有关示例，请参阅第 27 章中的“缓存”部分。

You may also find subsystems, such as the neighboring layer, that add a random component (regularly changed) to the key used to distribute elements in the cache's buckets. This is used to reduce the damage of Denial of Service (DoS) attacks aimed at concentrating the elements of a hash table into a single bucket. See the section "Caching" in Chapter 27 for an example.

当一段代码试图访问一个已经被释放的数据结构时，内核会不太高兴，而用户也很少会对内核的反应感到满意。为了避免这些令人讨厌的问题，并使垃圾收集机制更容易、更有效（请参阅“垃圾收集”部分）“在本章后面），大多数数据结构都会保留引用计数。优秀的内核公民每次保存和释放对结构的引用时都会分别增加和减少每个数据结构的引用计数。对于任何需要的数据结构类型引用计数，拥有该结构的内核组件通常导出两个可用于递增和递减引用计数的函数。这些函数通常分别称为 和。有时会调用release函数（例如，对于结构）。xxx _holdxxx _releasexxx _putdev_putnet_device

When a piece of code tries to access a data structure that has already been freed, the kernel is not very happy, and the user is rarely happy with the kernel's reaction. To avoid those nasty problems, and to make garbage collection mechanisms easier and more effective (see the section "Garbage Collection" later in this chapter), most data structures keep a reference count. Good kernel citizens increment and decrement the reference count of every data structure every time they save and release a reference, respectively, to the structure. For any data structure type that requires a reference count, the kernel component that owns the structure usually exports two functions that can be used to increment and decrement the reference count. Such functions are usually called xxx _hold and xxx _release, respectively. Sometimes the release function is called xxx _put instead (e.g., dev_put for net_device structures).

虽然我们喜欢假设内核中没有坏人，但开发人员也是人，因此他们并不总是编写没有错误的代码。使用引用计数是一种简单但有效的机制，可以避免释放仍然引用的数据结构。然而，它并不总能完全解决问题。这是忘记平衡增量和减量的结果：

While we like to assume there are no bad citizens in the kernel, developers are human, and as such they do not always write bug-free code. The use of the reference count is a simple but effective mechanism to avoid freeing still-referenced data structures. However, it does not always solve the problem completely. This is the consequence of forgetting to balance increments and decrements:

当由于某种原因要删除数据结构时，可以明确通知引用持有者该数据结构已消失，以便他们可以礼貌地释放其引用。这是通过通知链完成的。有关有趣的示例，请参阅第 8 章中的“引用计数”部分。

When a data structure is to be removed for some reason, the reference holders can be explicitly notified about its going away so that they can politely release their references. This is done through notification chains. See the section "Reference Counts" in Chapter 8 for an interesting example.

数据结构上的引用计数通常可以在以下情况下增加：

The reference count on a data structure typically can be incremented when:

当对数据结构的最后一个引用被释放时，它可能会被释放，因为不再需要它，但不一定。

When the last reference to a data structure is released, it may be freed because it is not needed anymore, but not necessarily.

新sysfs文件系统的引入有助于使大部分内核代码更加了解引用计数并使其使用保持一致。

The introduction of the new sysfs filesystem has helped to make a good portion of the kernel code more aware of reference counts and consistent in its use of them.

内存是一种共享且有限的资源，不应浪费，特别是在内核中，因为它不使用虚拟内存。大多数内核子系统都实现某种垃圾收集回收未使用或过时的数据结构实例所持有的内存。根据任何给定功能的需求，您会发现两种主要的垃圾收集：

Memory is a shared and limited resource and should not be wasted, particularly in the kernel because it does not use virtual memory. Most kernel subsystems implement some sort of garbage collection to reclaim the memory held by unused or stale data structure instances. Depending on the needs of any given feature, you will find two main kinds of garbage collection:

在第 7 章中，您将看到内核如何设法回收初始化例程使用的内存，并且在执行初始化例程后不再需要这些内存。

In Chapter 7, you will see how the kernel manages to reclaim the memory used by initialization routines and that is no longer needed after they have been executed.

函数指针是一种编写干净的 C 代码的便捷方法，同时还能获得面向对象语言的一些好处。在数据结构类型（对象）的定义中，包含一组函数指针（方法）。然后通过嵌入函数完成结构的部分或全部操作。数据结构中的 C 语言函数指针如下所示：

Function pointers are a convenient way to write clean C code while getting some of the benefits of the object-oriented languages. In the definition of a data structure type (the object), you include a set of function pointers (the methods). Some or all manipulations of the structure are then done through the embedded functions. C-language function pointers in data structures look like this:

结构袜子{
    ...
    void (*sk_state_change)(struct sock *sk);
    void (*sk_data_ready)(struct sock *sk, int bytes);
    ...

};

struct sock {
    ...
    void    (*sk_state_change)(struct sock *sk);
    void    (*sk_data_ready)(struct sock *sk, int bytes);
    ...

};

使用函数指针的一个关键优点是，它们可以根据不同的标准和对象所扮演的角色进行不同的初始化。因此，调用sk_state_change实际上可能为不同的sock套接字调用不同的函数。

A key advantage to using function pointers is that they can be initialized differently depending on various criteria and the role played by the object. Thus, invoking sk_state_change may actually invoke different functions for different sock sockets.

函数指针在网络代码中广泛使用。以下仅举几个例子：

Function pointers are used extensively in the networking code. The following are only a few examples:

我们在前面的示例中看到了如何将函数指针用作内核组件之间的接口或用作通用机制，以根据不同子系统完成的操作的结果在正确的时间调用正确的函数处理程序。在某些情况下，函数指针也被用作允许协议、设备驱动程序或任何其他功能个性化操作的简单方法。

We see in the preceding examples how function pointers can be employed as interfaces between kernel components or as generic mechanisms to invoke the right function handler at the right time based on the result of something done by a different subsystem. There are cases where function pointers are also used as a simple way to allow protocols, device drivers, or any other feature to personalize an action.

让我们看一个例子。当设备驱动程序向内核注册网络设备时，无论设备类型如何，它都会执行一系列所需的步骤。在某些时候，它会调用数据结构上的函数指针net_device，让设备驱动程序在需要时执行一些额外的操作。设备驱动程序可以将该函数指针初始化为它自己的函数，也可以将该指针保留为 NULL，因为内核执行的默认步骤就足够了。

Let's look at an example. When a device driver registers a network device with the kernel, it goes through a series of steps that are needed regardless of the device type. At some point, it invokes a function pointer on the net_device data structure to let the device driver do something extra if needed. The device driver could either initialize that function pointer to a function of its own, or leave the pointer NULL because the default steps performed by the kernel are sufficient.

在执行函数指针之前始终需要检查函数指针的值，以避免 NULL 指针取消引用，如下面的快照所示register_netdevice：

A check on the value of a function pointer is always necessary before executing it to avoid NULL pointer dereferences, as shown in this snapshot from register_netdevice:

    if (dev->init && dev->init(dev) != 0) {
        ...
    }

    if (dev->init && dev->init(dev) != 0) {
        ...
    }

函数指针有一个主要缺点：它们使浏览源代码变得有点困难。在浏览给定的代码路径时，您可能最终会关注函数指针调用。在这种情况下，在继续执行代码路径之前，您需要了解函数指针是如何初始化的。这可能取决于不同的因素：

Function pointers have one main drawback: they make browsing the source code a little harder. While going through a given code path, you may end up focusing on a function pointer call. In such cases, before proceeding down the code path, you need to find out how the function pointer has been initialized. It could depend on different factors:

分组到数据结构中的一组函数指针通常称为 虚拟函数表（VFT）。当 VFT 用作两个主要子系统（例如 L3 和 L4 协议层）之间的接口时，或者当 VFT 简单地导出为通用内核组件（对象集）的接口时，其中的函数指针数量可能会膨胀以包含许多不同的指针，以适应各种协议或其他功能。每个功能最终可能只使用所提供的众多功能中的几个。您将在第六部分中看到一个示例。当然，如果 VFT 的使用太过分，它就会变得很麻烦，并且需要进行重大的重新设计。

A set of function pointers grouped into a data structure are often referred to as a virtual function table (VFT). When a VFT is used as the interface between two major subsystems, such as the L3 and L4 protocol layers, or when the VFT is simply exported as an interface to a generic kernel component (set of objects), the number of function pointers in it may swell to include many different pointers that accommodate a wide range of protocols or other features. Each feature may end up using only a few of the many functions provided. You will see an example in Part VI. Of course, if this use of a VFT is taken too far, it becomes cumbersome and a major redesign is needed.

很少有 C 程序员喜欢这种goto说法。在不深入讨论goto（计算机编程中最长、最著名的争议之一）的历史的情况下，我将总结一些通常goto不赞成使用它的原因，以及为什么 Linux 内核仍然使用它。

Few C programmers like the goto statement. Without getting into the history of the goto (one of the longest and most famous controversies in computer programming), I'll summarize some of the reasons the goto is usually deprecated, but why the Linux kernel uses it anyway.

任何使用它的代码都goto可以在没有它的情况下重写。使用goto语句会降低代码的可读性，并使调试变得更加困难，因为在 a 之后的任何位置， goto您都无法再明确地导出导致执行到该点的条件。

Any piece of code that uses goto can be rewritten without it. The use of goto statements can reduce the readability of the code, and make debugging harder, because at any position following a goto you can no longer derive unequivocally the conditions that led the execution to that point.

让我打个比方：给定树中的任何节点，你都知道从根到该节点的路径是什么。但是，如果您添加随机缠绕在树枝上的藤蔓，则根和其他节点之间不再总是有唯一的路径。

Let me make this analogy: given any node in a tree, you know what the path from the root to the node is. But if you add vines that entwine around branches randomly, you do not always have a unique path between the root and the other nodes anymore.

然而，由于 C 语言不提供显式异常（并且由于性能影响和编码复杂性，在其他语言中通常也会避免它们），仔细放置语句可以更容易地跳转到处理不需要的或特殊事件的代码goto。在内核编程中，特别是在网络中，此类事件非常常见，因此goto成为一种方便的工具。

However, because the C language does not provide explicit exceptions (and they are often avoided in other languages as well because of the performance hit and coding complexity), carefully placed goto statements can make it easier to jump to code that handles undesired or peculiar events. In kernel programming, and particularly in networking, such events are very common, so goto becomes a convenient tool.

我必须为内核的使用辩护goto，指出开发人员绝没有对它疯狂。尽管有超过 30,000 个实例，但它们主要用于处理函数内的不同返回码，或者跳出多层嵌套。

I must defend the kernel's use of goto by pointing out that developers have by no means gone wild with it. Even though there are more than 30,000 instances, they are mainly used to handle different return codes within a function, or to jump out of more than one level of nesting.

在某些情况下，数据结构的定义末尾包含可选块。这是一个例子：

In some cases, the definition of a data structure includes an optional block at the end. This is an example:

结构 abc {
    年龄；
    字符*名称[20]；
    ...
    字符占位符[0]；
}

struct abc {
    int age;
    char *name[20];
    ...
    char    placeholder[0];
}

可选块以 开头placeholder。请注意，placeholder被定义为大小为 0 的向量。这意味着当abc与可选块一起分配时，placeholder指向块的开头。当不需要可选块时，placeholder只是指向结构末尾的指针；它不占用任何空间。

The optional block starts with placeholder. Note that placeholder is defined as a vector of size 0. This means that when abc is allocated with the optional block, placeholder points to the beginning of the block. When no optional block is required, placeholder is just a pointer to the end of the structure; it does not consume any space.

因此，如果abc被多段代码使用，则每段代码都可以使用相同的基本定义（避免以稍微不同的方式做同一件事的混乱），同时进行abc 不同的扩展以根据其需要个性化其定义。

Thus, if abc is used by several pieces of code, each one can use the same basic definition (avoiding the confusion of doing the same thing in slightly different ways) while extending abc differently to personalize its definition according to its needs.

我们会在书中多次看到这种数据结构的定义。第 19 章就是一个例子。

We will see this kind of data structure definition a few times in the book. One example is in Chapter 19.

有时需要向编译器提供条件指令。过度使用它们会降低代码的可读性，但我可以声明 Linux 不会滥用它们。它们出现的原因各不相同，但我们感兴趣的是那些用于检查内核是否支持给定功能的内容。配置工具（例如make xconfig） 确定该功能是否已编译、根本不支持或可作为模块加载。

Conditional directives to the compiler are sometimes necessary. An excessive use of them can reduce the readability of the code, but I can state that Linux does not abuse them. They appear for different reasons, but the ones we are interested in are those used to check whether a given feature is supported by the kernel. Configuration tools such as make xconfig determine whether the feature is compiled in, not supported at all, or loadable as a module.

C 预处理器指令的功能检查示例#ifdef包括#if defined：

Examples of feature checks by #ifdef or #if defined C preprocessor directives are:

变量和宏的定义或初始化也可以使用条件编译。

The definition or initialization of variables and macros can also use conditional compilation.

了解某些函数或宏的多个定义的存在非常重要，它们在编译时的选择基于预处理器宏，如前面的示例所示。否则，当您查找函数、变量或宏定义时，您可能会找错。

It is important to know about the existence of multiple definitions of certain functions or macros, whose selection at compile time is based on a preprocessor macro as in the preceding examples. Otherwise, when you look for a function, variable, or macro definition, you may be looking at the wrong one.

有关特殊宏的引入如何在某些情况下减少条件编译器指令的使用的讨论，请参阅第7 章。

See Chapter 7 for a discussion of how the introduction of special macros has reduced, in some cases, the use of conditional compiler directives.

大多数时候，当内核将变量与某些外部值进行比较以查看是否满足给定条件时，结果极有可能是可预测的。这很常见，例如，对于强制健全性检查的代码。内核分别使用likely和unlikely宏来包装可能返回 true (1) 或 false (0) 结果的比较。这些宏利用了gcc 编译器的一项功能，可以根据该信息优化代码的编译。

Most of the time, when the kernel compares a variable against some external value to see whether a given condition is met, the result is extremely likely to be predictable. This is pretty common, for example, with code that enforces sanity checks. The kernel uses the likely and unlikely macros, respectively, to wrap comparisons that are likely to return a true (1) or false (0) result. Those macros take advantage of a feature of the gcc compiler that can optimize the compilation of the code based on that information.

这是一个例子。假设您需要调用该do_something函数，并且在失败的情况下，您必须使用该handle_error函数进行处理：

Here is an example. Let's suppose you need to call the do_something function, and that in case of failure, you must handle it with the handle_error function:

错误 = do_something(x,y,z);
如果（错误）
    处理错误（错误）；

err = do_something(x,y,z);
if (err)
    handle_error(err);

在很少失败的假设下do_something，可以将代码重写如下：

Under the assumption that do_something rarely fails, you can rewrite the code as follows:

错误 = do_something(x,y,z);
如果（不太可能（错误））
    处理错误（错误）；

err = do_something(x,y,z);
if (unlikely(err))
    handle_error(err);

likely和宏实现的优化的一个例子unlikely是处理 IP 标头中的选项。IP 选项的使用仅限于非常特定的情况，并且内核可以安全地假设大多数 IP 数据包不携带 IP 选项。当内核转发IP数据包时，它需要根据第18章中描述的规则处理选项。转发 IP 数据包的最后阶段由 负责ip_forward_finish。该函数使用unlikely宏来包装检查是否有任何 IP 选项需要处理的条件。请参见第 20 章中的“ ip_forward_finish 函数”部分。

An example of the optimization made possible by the likely and unlikely macros is in handling options in the IP header. The use of IP options is limited to very specific cases, and the kernel can safely assume that most IP packets do not carry IP options. When the kernel forwards an IP packet, it needs to take care of options according to the rules described in Chapter 18. The last stage of forwarding an IP packet is taken care of by ip_forward_finish. This function uses the unlikely macro to wrap the condition that checks whether there is any IP option to take care of. See the section "ip_forward_finish Function" in Chapter 20.

锁定在网络代码中广泛使用，您可能会在本书的每个主题下看到它作为一个问题。对于许多类型的编程（尤其是内核编程）来说，互斥、锁定机制和同步是一个常见主题，也是一个非常有趣且复杂的主题。Linux 已经引入和优化了几种互斥方法 这些年来。因此，本节仅总结网络代码中的锁定机制；我建议您参阅 O'Reilly 的Understanding the Linux Kernel and Linux Device Driver中提供的高质量、详细的讨论 。

Locking is used extensively in the networking code, and you are likely to see it come up as an issue under every topic in this book. Mutual exclusion, locking mechanisms, and synchronization are a general topic—and a highly interesting and complex one—for many types of programming, especially kernel programming. Linux has seen the introduction and optimization of several approaches to mutual exclusion over the years. Thus, this section merely summarizes the locking mechanisms seen in networking code; I refer you to the high-quality, detailed discussions available in O'Reilly's Understanding the Linux Kernel and Linux Device Driver.

每种互斥机制都是针对特定情况的最佳选择。以下是您在网络代码中经常看到的替代互斥方法的简要总结：

Each mutual exclusion mechanism is the best choice for particular circumstances. Here is a brief summary of the alternative mutual exclusion approaches you will see often in the networking code:

信号量由内核提供，但很少在本书介绍的网络代码中使用。然而，一个例子是用于序列化配置更改的代码，我们将在第 8 章中看到它的实际效果。

Semaphores are offered by the kernel but are rarely used in the networking code covered in this book. One example, however, is the code used to serialize configuration changes, which we will see in action in Chapter 8.

跨越一个字节以上的数据结构可以以两种不同的格式存储在内存中：Little Endian 和 Big Endian。第一种格式将最低有效字节存储在最低内存地址处，第二种格式则相反。Linux 等操作系统使用的格式取决于所使用的处理器。例如，Intel 处理器遵循 Little Endian 模型，而 Motorola 处理器则使用 Big Endian 模型。

Data structures spanning more than one byte can be stored in memory with two different formats: Little Endian and Big Endian. The first format stores the least significant byte at the lowest memory address, and the second does the opposite. The format used by an operating system such as Linux depends on the processor in use. For example, Intel processors follow the Little Endian model, and Motorola processors use the Big Endian model.

假设我们的 Linux 机器从远程主机接收到一个 IP 数据包。因为它不知道远程主机使用哪种格式（Little Endian 或 Big Endian）来初始化协议标头，因此它将如何读取标头？因此，每个协议族都必须定义什么是“字节序”例如，TCP/IP 堆栈遵循 Big Endian 模型。

Suppose our Linux box receives an IP packet from a remote host. Because it does not know which format, Little Endian or Big Endian, was used by the remote host to initialize the protocol headers, how will it read the header? For this reason, each protocol family must define what "endianness " it uses. The TCP/IP stack, for example, follows the Big Endian model.

但这仍然给内核开发人员带来了一个问题：她必须编写可以在支持不同字节序的许多不同处理器上运行的代码。某些处理器可能会匹配传入数据包的字节顺序，但那些不需要转换为处理器使用的字节顺序的处理器。

But this still leaves the kernel developer with a problem: she must write code that can run on many different processors that support different endianness. Some processors might match the endianness of the incoming packet, but those that do not require conversion to the endianness used by the processor.

因此，每次内核需要读取、保存或比较跨越多个字节的 IP 标头字段时，它必须首先将其从网络字节顺序转换为主机字节顺序，反之亦然。这同样适用于 TCP/IP 堆栈的其他协议。当协议和本地主机都是 Big Endian 时，转换例程只是无操作，因为不需要任何转换。它们总是出现在代码中以使代码可移植；只有转换例程本身是平台相关的。表1-2列出了用于两字节和四字节字段转换的主要宏。

Therefore, every time the kernel needs to read, save, or compare a field of the IP header that spans more than one byte, it must first convert it from network byte order to host byte order or vice versa. The same applies to the other protocols of the TCP/IP stack. When both the protocol and the local host are Big Endian, the conversion routines are simply no-ops because there is no need for any conversion. They always appear in the code to make the code portable; only the conversion routines themselves are platform dependent. Table 1-2 lists the main macros used for the conversion of two-byte and four-byte fields.

这些宏在通用头文件include/linux/byteorder/generic.h中定义。这是每个架构如何根据这些宏的字节顺序来定制这些宏的定义：

The macros are defined in the generic header file include/linux/byteorder/generic.h. This is how each architecture tailors the definition of those macros based on their endianness:

对于表 1-2xxx中的每个宏，都有一个姊妹宏 ，当输入字段是常量值时使用，例如枚举列表的元素（参见第 28 章中的“ ARP​​ 协议初始化”部分的示例） ）。请注意，表 1-2中的宏通常在内核代码中使用，即使它们的输入是常量值（有关示例，请参见第 13 章中的“设置以太网协议和长度”部分）。_ _constant_ xxx

For each macro xxx in Table 1-2 there is a sister macro, _ _constant_ xxx, that is used when the input field is a constant value, such as an element of an enumeration list (see the section "ARP Protocol Initialization" in Chapter 28 for an example). Note that the macros in Table 1-2 are commonly used in the kernel code even when their input is a constant value (see the section "Setting the Ethernet Protocol and Length" in Chapter 13 for an example).

我们在本节前面说过，当数据字段跨越一个字节以上时，字节顺序很重要。当一个或多个字节的字段被定义为位字段的集合时，字节顺序实际上也很重要。例如，请参见第 18 章中的图 18-2中的 IPv4 标头，以及内核如何 在include/linux/ip.h中定义该结构。内核分别在前面提到的little_endian.h和big_endian.h文件中定义了和 。iphdr_ _LITTLE_ENDIAN_BITFIELD_ _BIG_ENDIAN_BITFIELD

We said earlier in the section that endianness is important when a data field spans more than one byte. Endianness is actually important also when a field of one or more bytes is defined as a collection of bitfields. See, for example, what the IPv4 header looks like in Figure 18-2 in Chapter 18, and how the kernel defines the iphdr structure in include/linux/ip.h. The kernel defines _ _LITTLE_ENDIAN_BITFIELD and _ _BIG_ENDIAN_BITFIELD, respectively, in the little_endian.h and big_endian.h files mentioned earlier.

一些函数应该在特定条件下被调用，或者在某些条件下不应该被调用。内核使用BUG_ON 和BUG_TRAP宏来捕获不满足此类条件的情况。当输入条件为BUG_TRAP假时，内核会打印一条警告消息。BUG_ON相反，打印一条错误消息并出现恐慌。

A few functions are supposed to be called under specific conditions, or are not supposed to be called under certain conditions. The kernel uses the BUG_ON and BUG_TRAP macros to catch cases where such conditions are not met. When the input condition to BUG_TRAP is false, the kernel prints a warning message. BUG_ON instead prints an error message and panics.

收集统计数据是一个好习惯关于特定条件的发生，例如缓存查找成功和失败、内存分配成功和失败等。对于每个收集统计数据的网络功能，本书都列出并描述了每个计数器。

It is a good habit for a feature to collect statistics about the occurrence of specific conditions, such as cache lookup successes and failures, memory allocation successes and failures, etc. For each networking feature that collects statistics, this book lists and describes each counter.

内核通常需要测量自给定时刻以来已经过去了多少时间。例如，执行 CPU 密集型任务的例程通常会在给定时间后释放 CPU。当重新安排执行时，它将继续其工作。即使内核支持内核抢占，这一点在内核代码中尤其重要。网络代码中的一个常见示例是实现垃圾收集的例程。我们将在本书中看到很多内容。

The kernel often needs to measure how much time has passed since a given moment. For example, a routine that carries on a CPU-intensive task often releases the CPU after a given amount of time. It will continue its job when it is rescheduled for execution. This is especially important in kernel code, even though the kernel supports kernel preemption. A common example in the networking code is given by the routines that implement garbage collection. We will see plenty in this book.

内核空间中时间的流逝以刻度为单位。时间间隔是定时器中断连续两次到期之间的时间。计时器负责不同的任务（我们在这里对它们不感兴趣）并且HZ 每秒定期到期。HZ是由依赖于体系结构的代码初始化的变量。例如，在 i386 机器上它被初始化为 1,000。这意味着当 Linux 在 i386 系统上运行时，计时器中断每秒到期 1,000 次，并且连续两次到期之间有 1 毫秒。

The passing of time in kernel space is measured in ticks . A tick is the time between two consecutive expirations of the timer interrupt. The timer takes care of different tasks (we are not interested in them here) and regularly expires HZ times per second. HZ is a variable initialized by architecture-dependent code. For example, it is initialized to 1,000 on i386 machines. This means that the timer interrupt expires 1,000 times per second when Linux runs on an i386 system, and that there is one millisecond between two consecutive expirations.

每次计时器到期时，它都会递增名为 的全局变量jiffies。这意味着在任何时间，jiffies代表自系统启动以来的滴答数，通用值n*HZ代表n时间的秒数。

Every time the timer expires it increments the global variable called jiffies. This means that at any time, jiffies represents the number of ticks since the system booted, and the generic value n*HZ represents n seconds of time.

如果函数需要的只是测量时间的流逝，它可以将 的值保存 jiffies到局部变量中，然后将 和 时间戳与时间间隔（以滴答数表示）之间的差异进行比较jiffies，以查看已经过去了多少时间自测量开始以来。

If all a function needs is to measure the passing of time, it can save the value of jiffies into a local variable and later compare the difference between jiffies and that timestamp against a time interval (expressed in number of ticks) to see how much time has passed since measurement started.

以下示例显示了一个需要执行某种工作但不希望占用 CPU 时间超过一个周期的函数。当通过设置为非零值do_something表示工作已完成时，该函数可以返回：job_done

The following example shows a function that needs to do some kind of work but does not want to hold the CPU for more than one tick. When do_something says the work is completed by setting job_done to a nonzero value, the function can return:

无符号长 start_time = jiffies;
int job_done = 0;
做 {
    do_something(&job_done);
    如果（工作完成）
        返回;
while (jiffies - 开始时间 < 1);

unsigned long start_time = jiffies;
int job_done = 0;
do {
    do_something(&job_done);
    If (job_done)
        return;
while (jiffies - start_time < 1);

有关使用实际内核代码的几个示例，请参阅第 10 章中的“积压处理：process_backlog Poll 虚拟函数”jiffies部分，或第 27 章中的“异步清理：neigh_periodic_timer 函数”部分。

For a couple of examples involving real kernel code using jiffies, see the section "Backlog Processing: The process_backlog Poll Virtual Function" in Chapter 10, or the section "Asynchronous cleanup: the neigh_periodic_timer function" in Chapter 27.

与任何其他大型动态软件一样，内核包含不再被调用的代码片段。不幸的是，您很少在代码中看到告诉您这一点的注释。有时您可能会发现自己在尝试理解如何使用给定函数或如何初始化给定变量时遇到困难，仅仅是因为您正在查看死代码。如果幸运的话，该代码不会编译，您可以猜测它的过时状态。其他时候你可能就没那么幸运了。

The kernel, like any other large and dynamic piece of software, includes pieces of code that are no longer invoked. Unfortunately, you rarely see comments in the code that tell you this. You may sometimes find yourself having trouble trying to understand how a given function is used or a given variable is initialized simply because you are looking at dead code. If you are lucky, that code does not compile and you can guess its out-of-date status. Other times you may not be that lucky.

每个内核子系统都应该分配一个或多个维护者。然而，一些维护人员只是有太多代码需要查看，而没有足够的空闲时间来完成。其他时候，他们可能对维护子系统失去了兴趣，但找不到任何替代品。因此，在查看似乎做了一些奇怪的事情或根本不遵守一般常识性编程规则的代码时，最好记住这一点。

Each kernel subsystem is supposed to be assigned one or more maintainers. However, some maintainers simply have too much code to look at, and insufficient free time to do it. Other times they may have lost interest in maintaining their subsystems but could not find any substitutes for their role. It is therefore good to keep this in mind when looking at code that seems to do something strange or that simply does not adhere to general, common-sense programming rules.

在本书中，只要有意义，我都会尝试提醒您有关未使用的函数、变量和数据结构字段的信息，可能是因为它们在删除功能时被遗漏，或者因为它们是为新功能而引入的，而该新功能的编码从未被使用过。完全的。

In this book, I tried, whenever meaningful, to alert you about functions, variables, and data structure fields that are not used, perhaps because they were left behind when removing a feature or because they were introduced for a new feature whose coding was never completed.

正如您通过查看 TCP/IP 规范或配置内核所看到的那样，网络代码提供了大量有用但并不总是必需的选项，例如防火墙、多播和其他功能。大多数这些选项都需要内核数据结构中的附加字段。因此，sk_buff充满了 C 预处理器#ifdef指令。例如，在定义底部附近sk_buff您可以找到：

As you can see from glancing at TCP/IP specifications or configuring a kernel, network code provides an enormous number of options that are useful but not always required, such as a Firewall, Multicasting, and other features. Most of these options require additional fields in kernel data structures. Therefore, sk_buff is peppered with C preprocessor #ifdef directives. For example, near the bottom of the sk_buff definition you can find:

结构体sk_buff {
    …………
#ifdef CONFIG_NET_SCHED
    _ _u32 tc_index；
#ifdef CONFIG_NET_CLS_ACT
    _ _u32 tc_verd；
    _ _u32 tc_classid；
＃万一
＃万一
}

struct sk_buff {
    ... ... ...
#ifdef CONFIG_NET_SCHED
    _ _u32    tc_index;
#ifdef CONFIG_NET_CLS_ACT
    _ _u32    tc_verd;
    _ _u32    tc_classid;
#endif
#endif
}

这表明，tc_index仅当符号在编译时定义时，该字段才是数据结构的一部分CONFIG_NET_SCHED，这意味着正确的选项（在本例中，“设备驱动程序 → 网络支持 → 网络选项 → QoS 和/或公平队列”）已由管理员或自动安装实用程序使用某些版本的make config启用。

This shows that the field tc_index is part of the data structure only if the CONFIG_NET_SCHED symbol is defined at compile time, which means that the right option (in this example, "Device Drivers → Networking support → Networking options → QoS and/or fair queueing") has been enabled with some version of make config by an administrator or by an automated installation utility.

CONFIG_NET_CLS_ACT前面的示例实际上显示了两个嵌套选项：仅当存在对“QoS 和/或公平排队”的支持时，才会考虑包含（数据包分类器）使用的字段。

The previous example actually shows two nested options: the fields used by CONFIG_NET_CLS_ACT (packet classifier) are considered for inclusion only if support for "QoS and/or fair queueing" is present.

顺便请注意，QoS 选项不能编译为模块。原因是，启用该选项的大部分后果在内核编译后将是不可逆的。一般来说，任何导致内核数据结构发生变化的选项（例如将字段添加tc_index到 sk_buff结构中）都会导致该选项不适合编译为模块。

Notice, by the way, that the QoS option cannot be compiled as a module. The reason is that most of the consequences of enabling the option will not be reversible after the kernel is compiled. In general, any option that causes a change in a kernel data structure (such as adding the tc_index field to the sk_buff structure) renders the option unfit to be compiled as a module.

您经常希望找出make config中的哪个编译选项或其变体与给定符号相关联#ifdef，以了解代码块何时包含在内核中。在 2.6 内核中，建立关联的最快方法是在遍布整个源代码树（每个目录一个）的kconfig文件中查找符号。在 2.4 内核中，您可以查阅文件Documentation/Configure.help。

You'll often want to find out which compile option from make config or its variants is associated with a given #ifdef symbol, to understand when a block of code is included in the kernel. The fastest way to make the association, in the 2.6 kernels, is to look for the symbol in the kconfig files that are spread all over the source tree (one per directory). In 2.4 kernels, you can consult the file Documentation/Configure.help.

的一些sk_buff字段的存在只是为了方便搜索和组织数据结构本身。内核将所有sk_buff结构维护在双向链表中。但这个列表的组织比传统的双向链表要复杂一些。

A few of the sk_buff's fields exist just to facilitate searching and to organize the data structure itself. The kernel maintains all sk_buff structures in a doubly linked list. But the organization of this list is somewhat more complicated than that of a traditional doubly linked list.

next与任何双向链表一样，该链表由每个结构中的和prev字段连接在一起sk_buff，next向前指向的字段和prev 向后指向的字段。但这个列表还有另一个要求：每个sk_buff结构必须能够快速找到整个列表的头部。为了实现这个要求，在列表的开头插入一个额外的类型结构sk_buff_head，作为一种虚拟元素。结构sk_buff_head是：

Like any doubly linked list, this one is tied together by next and prev fields in each sk_buff structure, the next field pointing forward and the prev field pointing backward. But this list has another requirement: each sk_buff structure must be able to find the head of the whole list quickly. To implement this requirement, an extra structure of type sk_buff_head is inserted at the beginning of the list, as a kind of dummy element. The sk_buff_head structure is:

结构体sk_buff_head {
    /* 这两个成员必须是第一个。*/
    结构sk_buff*下一个；
    结构 sk_buff * 前一个；

    _ _u32 qlen；
    spinlock_t 锁；
};

struct sk_buff_head {
    /* These two members must be first. */
    struct sk_buff    * next;
    struct sk_buff    * prev;

    _ _u32        qlen;
    spinlock_t    lock;
};

qlen表示列表中元素的数量。lock用于防止同时访问列表，并在本章后面的“列表管理功能”部分中进行描述。

qlen represents the number of elements in the list. lock is used to prevent simultaneous accesses to the list and is described in the section "List management functions," later in this chapter.

sk_buffand 的前两个元素sk_buff_head是相同的：thenext和prev指针。这允许两个结构共存于同一个列表中，尽管sk_buff_head与sk_buff. 此外，相同的函数可用于操作sk_buff和sk_buff_head。

The first two elements of both sk_buff and sk_buff_head are the same: the next and prev pointers. This allows the two structures to coexist in the same list, even though sk_buff_head is positively skimpy in comparison to sk_buff. In addition, the same functions can be used to manipulate both sk_buff and sk_buff_head.

为了增加复杂性，每个sk_buff结构都包含一个指向单个sk_buff_head 结构的指针。该指针具有字段名称list。请参阅 图 2-1以帮助您找到解决这些数据结构的方法。

To add to the complexity, every sk_buff structure contains a pointer to the single sk_buff_head structure. This pointer has the field name list. See Figure 2-1 for help finding your way around these data structures.

图 2-1。sk_buff 元素列表

Figure 2-1. List of sk_buff elements

其他有趣的领域sk_buff如下：

Other interesting fields of sk_buff follow:

sk_buff本节涵盖了与特定内核功能无关的大部分字段 ：

This section covers the majority of sk_buff fields, which are not associated with specific kernel features:

Linux 内核是模块化的，允许您选择包含哪些内容以及排除哪些内容。sk_buff因此，仅当内核编译为支持特定功能（例如防火墙（Netfilter）或 QoS）时，某些字段才会包含在数据结构中：

The Linux kernel is modular, allowing you to select what to include and what to leave out. Thus, some fields are included in the sk_buff data structure only if the kernel is compiled with support for particular features such as firewalling (Netfilter) or QoS:

功能很多，通常非常简短，由内核提供来操作sk_buff元素或元素列表。在图 2-4的帮助下 ，我将描述最重要的几个。首先，我们将看到用于分配和释放缓冲区的函数，然后是用于操作指针（即skb->data）以在帧的头部或尾部保留空间的函数。

Lots of functions , usually very short and simple, are offered by the kernel to manipulate sk_buff elements or lists of elements. With the help of Figure 2-4, I'll describe the most important ones. First we will see the functions used to allocate and free buffers, and then the ones used to manipulate the pointers (i.e., skb->data) to reserve space at the head or at the tail of a frame.

如果您查看文件include/linux/skbuff.h和net/core/skbuff.c，您会注意到几乎所有函数都存在两个版本，名称类似于do_something和 _ _do_something。通常，第一个是一个包装器，它在对第二个的调用周围添加额外的健全性检查或锁定机制。通常不直接调用内部_ _do_something形式（除非满足特定条件，例如，锁定要求）。该规则的例外情况通常是编码不良的函数，这些函数最终将被修复。

If you take a look at the files include/linux/skbuff.h and net/core/skbuff.c, you will notice that almost all of the functions exist in two versions, with names like do_something and _ _do_something. Usually, the first one is a wrapper that adds extra sanity checks or locking mechanisms around a call to the second one. The internal _ _do_something form is generally not called directly (unless specific conditions are met—i.e., lock requirements, to name one). Exceptions to that rule are usually poorly coded functions that will be fixed eventually.

图 2-4。前后：(a)skb_put、(b)skb_push、(c)skb_pull 和 (d)skb_reserve

Figure 2-4. Before and after: (a)skb_put, (b)skb_push, (c)skb_pull, and (d)skb_reserve

分配内存：alloc_skb 和 dev_alloc_skb

Allocating memory: alloc_skb and dev_alloc_skb

alloc_skb是分配缓冲区的主要函数，在net/core/skbuff.c中定义。我们已经看到，数据缓冲区和标头（sk_buff数据结构）是两个不同的实体，这意味着创建单个缓冲区涉及两次内存分配（一项用于缓冲区，一项用于结构sk_buff ）。

alloc_skb is the main function for the allocation of buffers and is defined in net/core/skbuff.c. We have already seen that the data buffer and the header (the sk_buff data structure) are two different entities, which means that creating a single buffer involves two allocations of memory (one for the buffer and one for the sk_buff structure).

alloc_skbsk_buff通过调用 函数 从缓存中获取 数据结构kmem_cache_alloc，并通过调用 获取数据缓冲区kmalloc，如果缓存内存可用，它也会使用缓存内存。代码（稍微简化）是：

alloc_skb takes an sk_buff data structure from a cache by calling the function kmem_cache_alloc, and gets a data buffer by calling kmalloc, which also uses cached memory if it is available. The code (slightly simplified) is:

    skb = kmem_cache_alloc(skbuff_head_cache, gfp_mask & ~_ _GFP_DMA);
    …………
    大小 = SKB_DATA_ALIGN(大小);
    数据 = kmalloc(size + sizeof(struct skb_shared_info), gfp_mask);

    skb = kmem_cache_alloc(skbuff_head_cache, gfp_mask & ~_ _GFP_DMA);
    ... ... ...
    size = SKB_DATA_ALIGN(size);
    data = kmalloc(size + sizeof(struct skb_shared_info), gfp_mask);

在调用之前kmalloc，size使用宏调整参数SKB_DATA_ALIGN以强制对齐。在返回之前，该函数会初始化结构体中的一些参数，产生 如图 2-5所示的最终结果。

Before calling kmalloc, the size parameter is tuned with the macro SKB_DATA_ALIGN to force alignment. Before returning, the function initializes a few parameters in the structure, producing the final result shown in Figure 2-5.

在图 2-5右侧内存块的底部，您可以看到为强制对齐而引入的填充区域。该skb_shared_info块主要用于处理IP 分片，本章稍后将对此进行介绍。前面已经解释了图左侧显示的字段。

At the bottom of the memory block on the right side of Figure 2-5 you can see the padding area introduced to force the alignment. The skb_shared_info block is mainly used to handle IP fragments and is described later in this chapter. The fields shown on the left side of the figure were explained earlier.

图 2-5。alloc_skb函数

Figure 2-5. alloc_skb function

dev_alloc_skb是供设备驱动程序使用的缓冲区分配函数，预计在中断模式下执行。它只是一个包装器alloc_skb，出于优化原因将 16 个字节添加到请求的大小，并要求原子操作 ( GFP_ATOMIC)，因为它将从中断处理程序例程中调用：

dev_alloc_skb is the buffer allocation function meant for use by device drivers and expected to be executed in interrupt mode. It is simply a wrapper around alloc_skb that adds 16 bytes to the requested size for optimization reasons and asks for an atomic operation (GFP_ATOMIC) since it will be called from within an interrupt handler routine:

静态内联结构体 sk_buff *dev_alloc_skb(unsigned int length)
{
    返回 _ _dev_alloc_skb(长度, GFP_ATOMIC);
}


静态内联
struct sk_buff *_ _dev_alloc_skb(unsigned int length, int gfp_mask)
{
    struct sk_buff *skb = alloc_skb(长度 + 16, gfp_mask);
    如果（可能（skb））
            skb_reserve(skb, 16);
    返回skb；
}

static inline struct sk_buff *dev_alloc_skb(unsigned int length)
{
    return _ _dev_alloc_skb(length, GFP_ATOMIC);
}


static inline
struct sk_buff *_ _dev_alloc_skb(unsigned int length, int gfp_mask)
{
    struct sk_buff *skb = alloc_skb(length + 16, gfp_mask);
    if (likely(skb))
            skb_reserve(skb, 16);
    return skb;
}

_ _dev_alloc_skb当没有特定于体系结构的定义时，此定义是默认使用的定义。

This definition of _ _dev_alloc_skb is the default one used when there is no architecture-specific definition.

数据保留和对齐：skb_reserve、skb_put、skb_push 和 skb_pull

Data reservation and alignment: skb_reserve, skb_put, skb_push, and skb_pull

skb_reserve在缓冲区的头部保留一些空间（净空），通常用于允许插入标头或强制数据在某些边界上对齐。该函数移动分别标记有效负载的开始和结束的 data和指针（在前面的“布局字段tail”部分中讨论）。图2-4(d)显示了调用的结果。该函数通常在分配缓冲区后不久调用，此时和仍然相同。skb_reserve(skb,n)datatail

skb_reserve reserves some space (headroom) at the head of the buffer and is commonly used to allow the insertion of a header or to force data to be aligned on some boundary. The function shifts the data and tail pointers (discussed earlier in the section "Layout Fields") that mark the beginning and the end of the payload, respectively. Figure 2-4(d) shows the result of calling skb_reserve(skb,n). This function is usually called soon after the allocation of the buffer, when data and tail are still the same.

如果您查看其中一个以太网驱动程序的接收函数（例如， vortex_rx在drivers/net/3c59x.c中），您将看到它们在将任何数据存储到刚刚分配的缓冲区中之前都使用以下命令：

If you look at the receive function of one of the Ethernet drivers (for instance, vortex_rx in drivers/net/3c59x.c) you will see that they all use the following command before storing any data in the buffer they have just allocated:

skb_reserve(skb, 2); /* 在 16 字节边界上对齐 IP */

skb_reserve(skb, 2);    /* Align IP on 16 byte boundaries */

图 2-6。kfree_skb 函数

Figure 2-6. kfree_skb function

因为他们知道他们即将将一个具有 14 个八位字节长的报头的以太网帧复制到缓冲区中，所以参数将2 缓冲区的头部移动 2 个字节。这使得紧随以太网报头之后的 IP 报头从缓冲区的开头开始在 16 字节边界上对齐，如图2-7所示。

Because they know that they are about to copy an Ethernet frame that has a header 14 octets long into the buffer, the argument of 2 shifts the head of the buffer 2 bytes. This keeps the IP header, which follows immediately after the Ethernet header, aligned on a 16-byte boundary from the beginning of the buffer, as shown in Figure 2-7.

图 2-7。(a) skb_reserve 之前，(b) skb_reserve 之后，(c) 将帧复制到缓冲区之后

Figure 2-7. (a) before skb_reserve, (b) after skb_reserve, and (c) after copying the frame on the buffer

图 2-8skb_reserve显示了数据传输过程中反向使用的示例。

Figure 2-8 shows an example of using skb_reserve in the opposite direction, during data transmission.

图 2-8。从 TCP 层向下遍历堆栈到链路层时填充的缓冲区

Figure 2-8. Buffer that is filled in while traversing the stack from the TCP layer down to the link layer

1. 当 TCP 被要求传输某些数据时，它会按照特定标准（TCP 最大段大小 (mss)、支持分散收集 I/O 等）分配缓冲区。

2. When TCP is asked to transmit some data, it allocates a buffer following certain criteria (TCP Maximum Segment Size (mss), support for scatter gather I/O, etc.).

3. TCPskb_reserve在缓冲区的头部保留（用 ）足够的空间来容纳所有层（TCP、IP、链路层）的所有标头。该参数MAX_TCP_HEADER是各级所有报头的总和，并且在计算时考虑了最坏的情况：因为TCP层不知道将使用什么类型的接口进行传输，所以它为每一层保留最大可能的报头。它甚至考虑了多个 IP 标头的可能性（因为当内核编译为支持 IP over IP 时，您可以拥有多个 IP 标头）。

4. TCP reserves (with skb_reserve) enough space at the head of the buffer to hold all the headers of all layers (TCP, IP, link layer). The parameter MAX_TCP_HEADER is the sum of all headers of all levels and is calculated taking into account the worst-case scenarios: because the TCP layer does not know what type of interface will be used for the transmission, it reserves the biggest possible header for each layer. It even accounts for the possibility of multiple IP headers (because you can have multiple IP headers when the kernel is compiled with support for IP over IP).

5. TCP 有效负载被复制到缓冲区中。请注意，图 2-8只是一个示例。TCP 有效负载可以以不同的方式组织；例如，它可以存储为片段。在第 21 章中，我们将看到分段缓冲区（通常也称为分页缓冲区）是什么样子。

6. The TCP payload is copied into the buffer. Note that Figure 2-8 is just an example. The TCP payload could be organized differently; for example, it could be stored as fragments. In Chapter 21, we will see what a fragmented buffer (also commonly called a paged buffer) looks like.

7. TCP 层添加其标头。

8. The TCP layer adds its header.

9. TCP 层将缓冲区交给 IP 层，IP 层也添加其标头。

10. The TCP layer hands the buffer to the IP layer, which adds its header as well.

11. IP 层将 IP 数据包传递给相邻层，相邻层添加链路层标头。

12. The IP layer hands the IP packet to the neighboring layer, which adds the link layer header.

请注意，当缓冲区沿着网络堆栈向下移动时，每个协议都会 skb->data向下移动，复制其标头并更新skb->len。所有这些都是通过我们在图 2-4中看到的函数来完成的。

Note that while the buffer travels down the network stack, each protocol moves skb->data down, copies in its header, and updates skb->len. All of this is accomplished with the functions we saw in Figure 2-4.

请注意，该skb_reserve函数实际上并没有将任何内容移入数据缓冲区或数据缓冲区内。它只是更新两个指针，如图2-4(d)所示。

Note that the skb_reserve function does not really move anything into or within the data buffer; it simply updates the two pointers as depicted in Figure 2-4(d).

静态内联 void skb_reserve(struct sk_buff *skb, unsigned int len)
{
    skb->data+=len；
    skb->tail+=len；
}

static inline void skb_reserve(struct sk_buff *skb, unsigned int len)
{
    skb->data+=len;
    skb->tail+=len;
}

skb_push在缓冲区的开头添加一个数据块，并skb_put在末尾添加一个数据块。就像skb_reserve，这些函数实际上并没有向缓冲区添加任何数据；而是将它们添加到缓冲区中。他们只需将指针移动到其头部或尾部即可。新数据应该由其他函数显式复制。skb_pull通过向前移动指针从缓冲区头部删除数据块head。图 2-4显示了这些函数的工作原理。

skb_push adds one block of data to the beginning of the buffer, and skb_put adds one to the end. Like skb_reserve, these functions don't really add any data to the buffer; they simply move the pointers to its head or tail. The new data is supposed to be copied explicitly by other functions. skb_pull removes a block of data from the head of the buffer by moving the head pointer forward. Figure 2-4 shows how these functions work.

结构体skb_shared_info {
    原子_t 数据引用；
    无符号整数nr_frags；
    无符号短 tso_size；
    无符号短 tso_seqs；
    结构 sk_buff *frag_list;
    skb_frag_t 碎片[MAX_SKB_FRAGS];
};

struct skb_shared_info {
    atomic_t        dataref;
    unsigned int    nr_frags;
    unsigned short  tso_size;
    unsigned short  tso_seqs;
    struct sk_buff  *frag_list;
    skb_frag_t      frags[MAX_SKB_FRAGS];
};

#define skb_shinfo(SKB) ((struct skb_shared_info *)((SKB)->end))

#define skb_shinfo(SKB)    ((struct skb_shared_info *)((SKB)->end))

skb_shinfo(skb)->nr_frags++;

skb_shinfo(skb)->nr_frags++;

克隆和复制缓冲区

Cloning and copying buffers

当同一个缓冲区需要由不同的消费者独立处理时，并且他们可能需要更改描述符的内容 sk_buff（h和nh指向协议头的指针），内核不需要对结构sk_buff和协议头进行完整的复制。相关的数据缓冲区。相反，为了提高效率，内核可以克隆原始数据，这包括仅复制结构sk_buff 并使用引用计数以避免过早释放共享数据块。缓冲区克隆是通过该skb_clone函数完成的。

When the same buffer needs to be processed independently by different consumers, and they may need to change the content of the sk_buff descriptor (the h and nh pointers to the protocol headers), the kernel does not need to make a complete copy of both the sk_buff structure and the associated data buffers. Instead, to be more efficient, the kernel can clone the original, which consists of making a copy of the sk_buff structure only and playing with the reference counts to avoid releasing the shared data block prematurely. Buffer cloning is done with the skb_clone function.

使用克隆的情况的一个示例是，需要将入口数据包传递给多个接收者，例如协议处理程序和一个或多个网络分流器（请参阅第 21 章）。

An example of a situation using cloning is when an ingress packet needs to be delivered to multiple recipients, such as the protocol handler and one or more network taps (see Chapter 21).

克隆sk_buff不链接到任何列表，也不引用套接字所有者。该字段skb->cloned在克隆缓冲区和原始缓冲区中均设置为 1。 skb->users在克隆中设置为 1，以便第一次尝试删除它会成功，并且对包含数据的缓冲区的引用 () 数量dataref会增加（因为现在又有一个sk_buff数据结构指向它）。图 2-9显示了克隆缓冲区的示例。

The sk_buff clone is not linked to any list and has no reference to the socket owner. The field skb->cloned is set to 1 in both the clone and the original buffer. skb->users is set to 1 in the clone so that the first attempt to remove it succeeds, and the number of references (dataref) to the buffer containing the data is incremented (since now there is one more sk_buff data structure pointing to it). Figure 2-9 shows an example of a cloned buffer.

图 2-9。skb_clone函数

Figure 2-9. skb_clone function

该skb_clone例程可用于检查skb 缓冲区的克隆状态。

The skb_clone routine can be used to check the cloned status of an skb buffer.

图 2-9 显示了分段缓冲区的示例，也就是说，缓冲区中存储了一些与数组链接的数据片段中的数据frags 。我们将在第 21 章中看到如何使用分段缓冲区；现在，我们先不要理会这些细节。

Figure 2-9 shows an example of a fragmented buffer—that is to say, a buffer that has some data stored in data fragments linked with the frags array. We will see how fragmented buffers are used in Chapter 21; for now, let's not bother with those details.

该skb_share_check 例程可用于检查引用计数skb->users并在字段表明缓冲区是共享skb 时克隆users缓冲区。

The skb_share_check routine can be used to check the reference count skb->users and clone the buffer skb when the users field says the buffer is shared.

当缓冲区被克隆时，数据块的内容不能被修改。这意味着代码可以访问数据而无需锁定。然而，当函数不仅需要修改结构的内容sk_buff还需要修改数据时，它还需要克隆数据块。在这种情况下，程序员有两个选择。skb->start当他知道他只需要修改和之间的区域中的数据内容时skb->end，他可以使用pskb_copy克隆该区域。当他认为他可能也需要修改片段数据块的内容时，他必须使用skb_copy. 两者的结果pskb_copy如图2-10skb_copy所示。您将在第 21 章中看到 ，skb_shared_info数据结构也可以包含结构列表sk_buff（链接到名为 的字段frag_list）。该列表由数组处理pskb_copy，处理skb_copy 方式与数组相同（图 2-10frags中省略了此细节，以保持后者更具可读性）。

When a buffer is cloned, the contents of the data block cannot be modified. This means that code can access the data without any need for locking. When, however, a function needs to modify not only the contents of the sk_buff structure but the data too, it needs to clone the data block as well. In this case, the programmer has two options. When he knows he needs to modify only the contents of the data in the area between skb->start and skb->end, he can use pskb_copy to clone just that area. When he thinks he may need to modify the content of the fragment data blocks too, he must use skb_copy. The result of both pskb_copy and skb_copy is shown in Figure 2-10. You will see in Chapter 21 that the skb_shared_info data structure can include a list of sk_buff structures too (linked to a field called frag_list). That list is handled by pskb_copy and skb_copy in the same way as the frags array (this detail has been omitted from Figure 2-10 to keep the latter more readable).

图 2-10。(a) pskb_copy 函数和 (b) skb_copy 函数

Figure 2-10. (a) pskb_copy function and (b) skb_copy function

此时您可能无法理解 图 2-9和2-10中的所有细节。在本书的后面部分，尤其是当您读完第五部分后，一切都会变得更有意义。

You may not be able to appreciate all of the details in Figures 2-9 and 2-10 at this point. Later in the book, especially once you have gone through Part V, everything will make more sense.

在讨论本书的各个主题时，我有时会强调给定的函数需要克隆或复制缓冲区。当决定克隆或复制缓冲区时，每个子系统的程序员无法预测其他内核组件（或其子系统的其他用户）是否需要该缓冲区中的原始信息。内核是非常模块化的，并且以非常动态和不可预测的方式进行更改，因此每个子系统都不知道其他子系统可能会使用缓冲区做什么。因此，每个子系统的程序员只需跟踪他们对缓冲区所做的任何修改，

While discussing the various topics of this book, I will sometimes emphasize that a given function needs to clone or copy a buffer. When deciding to make a clone or copy of a buffer, programmers of each subsystem cannot anticipate whether other kernel components (or other users of their subsystems) will need the original information in that buffer. The kernel is very modular and changes in a very dynamic and unpredictable way, so each subsystem is ignorant of what other subsystems may do with a buffer. Therefore, the programmers of each subsystem just keep track of any modifications they make to the buffer, and take care to make a copy before modifying anything in case some other part of the kernel needs the original information.

静态内联function_name( parameter_list)
{
        无符号长标志；

        spin_lock_irqsave(...);
        _ _ _ function_name( parameter_list)
        spin_unlock_irqrestore(...);
}

static inline function_name ( parameter_list )
{
        unsigned long flags;

        spin_lock_irqsave(...);
        _ _ _function_name ( parameter_list )
        spin_unlock_irqrestore(...);
}

该net_device结构体包含三个标识符， 不被混淆：

The net_device structure includes three identifiers , not to be confused:

一些配置字段内核根据网络设备的类别给定一个默认值，并且一些字段留给驱动程序来填充。如前所述，驱动程序可以更改默认值，甚至可以通过ifconfig和等命令在运行时更改某些字段ip。事实上，几个参数—— base_addr、if_port、dma、and irq——通常是由用户在加载设备模块时设置的。另一方面，虚拟设备不使用这些参数。

Some of the configuration fields are given a default value by the kernel that depends on the class of network device, and some fields are left to the driver to fill. The driver can change defaults, as mentioned earlier, and some fields can even be changed at runtime by commands such as ifconfig and ip. In fact, several parameters—base_addr, if_port, dma, and irq—are commonly set by the user when the module for the device is loaded. On the other hand, these parameters are not used by virtual devices.

以太网 MTU 值得稍微澄清一下。以太网帧规范将最大有效负载大小定义为 1,500 字节。有时您会发现以太网 MTU 定义为 1,518 或 1,514：第一个是包括标头的以太网帧的最大大小，第二个包括标头但不包括帧校验序列（4 个字节的校验和）。

The Ethernet MTU deserves a little clarification. The Ethernet frame specification defines the maximum payload size as 1,500 bytes. Sometimes you find the Ethernet MTU defined as 1,518 or 1,514: the first is the maximum size of an Ethernet frame including the header, and the second includes the header but not the frame check sequence (4 bytes of checksum).

1998年，Alteon Networks（2000年被北电网络收购）提出了一项计划，将以太网帧的最大有效负载增加到9 KB。该提案后来通过 IETF 互联网草案正式确定，但 IEEE 从未接受。IEEE 规范中超过 1,500 字节有效负载的帧通常称为巨型帧，与千兆位以太网一起使用以提高吞吐量。这是因为较大的帧意味着用于大数据传输的帧较少、中断较少，因此 CPU 使用率较低、标头开销较低等）。有关增加以太网 MTU 的好处以及 IEEE 不同意标准化此扩展的原因的讨论，http://www.ietf.org/proceedings/01aug/ID/draft-ietf-isis-ext-eth-01.txt。

In 1998, Alteon Networks (acquired by Nortel Networks in 2000) promoted an initiative to increase the maximum payload of Ethernet frames to 9 KB. This proposal was later formalized with an IETF Internet draft, but the IEEE never accepted it. Frames exceeding the 1,500 bytes of payload in the IEEE specification are commonly called jumbo frames and are used with Gigabit Ethernet to increase throughput. This is because bigger frames mean fewer frames for large data transfers, fewer interrupts, and therefore less CPU usage, less header overhead, etc.). For a discussion of the benefits of increasing the Ethernet MTU and why IEEE does not agree on standardizing this extension, you can read the white paper "Use of Extended Frame Sizes in Ethernet Networks" that can be found with an Internet search, as well as at http://www.ietf.org/proceedings/01aug/I-D/draft-ietf-isis-ext-eth-01.txt.

        开关（dev->if_port）{
        情况 IF_PORT_10BASE2：
            writeb((readb(addr) & 0xf8) | 1, addr);
            休息;
        案例 IF_PORT_10BASET：
            writeb((readb(addr) & 0xf8), addr);
            休息;
        }

        switch (dev->if_port) {
        case IF_PORT_10BASE2:
            writeb((readb(addr) & 0xf8) | 1, addr);
            break;
        case IF_PORT_10BASET:
            writeb((readb(addr) & 0xf8), addr);
            break;
        }

静态无效set_rx_mode（结构net_device * dev）
{
        int ioaddr = dev->base_addr;
        int new_mode;

        if (dev->flags & IFF_PROMISC) {
             如果（corqscreq_debug > 3）
                        printk("%s: 设置混杂模式。\n", dev->name);
             new_mode = 设置RxFilter | 接收站 | Rx多播| Rx广播| RxProm；
        } else if ((dev->mc_list) || (dev->flags & IFF_ALLMULTI)) {
             new_mode = 设置RxFilter | 接收站 | Rx多播| 接收广播；
        } 别的
             new_mode = 设置RxFilter | 接收站 | 接收广播；

        outw(new_mode, ioaddr + EL3_CMD);
}

static void set_rx_mode(struct net_device *dev)
{
        int ioaddr = dev->base_addr;
        int new_mode;

        if (dev->flags & IFF_PROMISC) {
             if (corqscreq_debug > 3)
                        printk("%s: Setting promiscuous mode.\n", dev->name);
             new_mode = SetRxFilter | RxStation | RxMulticast | RxBroadcast | RxProm;
        } else if ((dev->mc_list)  ||  (dev->flags & IFF_ALLMULTI)) {
             new_mode = SetRxFilter | RxStation | RxMulticast | RxBroadcast;
        } else
             new_mode = SetRxFilter | RxStation | RxBroadcast;

        outw(new_mode, ioaddr + EL3_CMD);
}

而不是提供字段集合来保存统计信息，该net_device结构包括一个名为 的指针priv，该指针由驱动程序设置为指向存储有关接口的信息的私有数据结构。私有数据由统计数据组成，例如发送和接收的数据包数量以及遇到的错误数量。

Instead of providing a collection of fields to keep statistics , the net_device structure includes a pointer named priv that is set by the driver to point to a private data structure storing information about the interface. The private data consists of statistics such as the number of packets transmitted and received and the number of errors encountered.

由 指向的结构的格式priv 取决于设备类型和特定型号：因此，不同的以太网卡可以使用不同的私有结构。然而，几乎所有结构都包含一个类型字段（在include/linux/netdevice.hnet_device_stats中定义），该字段包含所有网络设备共有的统计信息，并且可以使用稍后描述的方法检索。get_stats

The format of the structure pointed at by priv depends both on the device type and on the particular model: thus, different Ethernet cards may use different private structures. However, nearly all structures include a field of type net_device_stats (defined in include/linux/netdevice.h) that contains statistics common to all the network devices and that can be retrieved with the method get_stats, described later.

无线设备的行为与有线设备如此不同，以至于无线设备找不到net_device_stats合适的数据结构。相反，它们提供了一个类型的字段iw_statistics ，可以使用get_wireless_stats稍后描述的名为 的方法来检索该字段。

Wireless devices behave so differently from wired devices that wireless ones do not find the net_device_stats data structure appropriate. Instead, they provide a field of type iw_statistics that can be retrieved using a method called get_wireless_stats, described later.

指向的数据结构priv有时具有反映接口的名称（例如，vortex_private对于 Vortex 和 Boomerang 系列，也称为 3c59x 系列），而其他时候则简称为net_local。尽管如此， 中的字段net_local仍然由每个设备驱动程序唯一定义。

The data structure to which priv points sometimes has a name reflecting the interface (e.g., vortex_private for the Vortex and Boomerang series, also called the 3c59x family), and other times is simply called net_local. Still, the fields in net_local are defined uniquely by each device driver.

私有数据结构可能或多或少复杂，具体取决于卡的功能以及设备驱动程序编写者愿意采用复杂的统计数据和复杂的设计来增强性能的程度。例如，将 drivers/net/3c507.cnet_local中 3c507 以太网卡使用的通用结构与drivers/net/3c59x.c中 3c59x 以太网卡使用的高度详细的 结构进行比较。然而，两者都包含一个 类型的字段。vortex_privatenet_device_stats

The private data structure may be more or less complex depending on the card's capabilities and on how much the device driver writer is willing to employ sophisticated statistics and complex design to enhance performance. Compare, for instance, the generic net_local structure used by the 3c507 Ethernet card in drivers/net/3c507.c with the highly detailed vortex_private structure used by the 3c59x Ethernet card in drivers/net/3c59x.c. Both, however, include a field of type net_device_stats.

正如您将在第 8 章中看到的，私有数据结构有时会附加到net_device结构本身（malloc两者只需要一个），有时会分配为单独的块。

As you will see in Chapter 8, the private data structure is sometimes appended to the net_device structure itself (requiring only one malloc for both) and sometimes allocated as a separate block.

为了控制与 NIC 的交互，每个设备驱动程序都必须维护诸如时间戳和指示接口需要哪种行为的标志等信息。在对称多处理 (SMP) 系统中，内核还必须确保正确处理不同 CPU 对同一设备的并发访问。该结构的几个字段net_device专用于这些类型的信息：

To control interactions with the NIC, each device driver has to maintain information such as timestamps and flags indicating what kind of behavior the interface requires. In a symmetric multiprocessing (SMP) system, the kernel also has to make sure that concurrent accesses to the same device from different CPUs are handled correctly. Several fields of the net_device structure are dedicated to these types of information:

net_device数据结构被插入到一个全局列表和两个哈希表中，如第 8 章所述。以下字段用于完成这些任务：

net_device data structures are inserted into a global list and into two hash tables, as described in Chapter 8. The following fields are used to accomplish these tasks:

多播是一种用于将数据传送给多个接收者的机制。组播可在 L3 网络层（即 IP）和 L2 链路层（即以太网）上使用。在本节中，我们关注的是后者。

Multicast is a mechanism used to deliver data to multiple recipients. Multicasting can be available both at the L3 network layer (i.e., IP) and at the L2 link layer (i.e., Ethernet). In this section, we are concerned with the latter.

链路层多播传送可以通过使用链路层报头中的特殊地址或控制信息来实现。（当链路层协议不支持时，可以对其进行仿真。）以太网本身支持多播：我们将在第 13 章中看到以太网地址如何分为单播、多播或广播。

Link layer multicast delivery can be achieved by using special addresses or control information in the link layer header. (When it is not supported by the link layer protocol, it may be emulated.) Ethernet natively supports multicasting: we will see in Chapter 13 how an Ethernet address can be classified as unicast, multicast, or broadcast.

多播地址通过特定位与其他地址范围区分开来。这意味着 50% 的可能地址是多播的，2 ⁴⁸中的 50%是一个巨大的数字！当一个接口被要求加入许多多播组（每个多播组由一个多播地址标识）时，简单地侦听所有多播地址可能会更高效、更快速，而不是维护一个长列表并浪费时间过滤入口 L2基于列表的多播帧。flags数据结构中的其中之一net_device指示设备是否应该监听所有地址。关于何时设置或清除该标志的决定由all_multi本节中显示的字段。

Multicast addresses are distinguished from the range of other addresses by a specific bit. This means that 50% of the possible addresses are multicast, and 50% of 2⁴⁸ is a huge number! When an interface is asked to join a lot of multicast groups (each identified by a multicast address), it may be more efficient and faster for it to simply listen to all the multicast addresses instead of maintaining a long list and wasting time filtering ingress L2 multicast frames based on the list. One of the flags in the net_device data structure indicates whether the device should listen to all addresses. The decision about when to set or clear this flag is controlled by the all_multi field shown in this section.

dev_mc_list 每个设备为每个链路层多播保留一个结构实例解决它所听的问题。dev_mc_add链路层组播地址可以分别用和函数添加和删除dev_mc_delete。net-device结构中的相关字段包括：

Each device keeps an instance of the dev_mc_list structure for each link layer multicast address it listens to. Link layer multicast addresses can be added and removed with the functions dev_mc_add and dev_mc_delete, respectively. Relevant fields in the net-device structure include:

Linux 的流量控制子系统已经发展了很多，代表了 Linux 内核的优势之一。相关的内核选项是“设备驱动程序 → 网络支持 → 网络选项 → QoS 和/或公平队列”。net-device结构中的相关字段 包括：

The Traffic Control subsystem of Linux has grown quite a lot and represents one of the strengths of the Linux kernel. The associated kernel option is "Device drivers → Networking support → Networking options → QoS and/or fair queueing." Relevant fields in the net-device structure include:

正如我们在描述时看到的，只有当它们所属的功能已包含在内核中时，sk_buff一些参数才会包含在定义中： ^{[ 1 ]}net_device

As we saw when describing sk_buff, a few parameters are included in the definition of net_device only if the features they belong to have been included in the kernel:^[1]

除了net_device 前面讨论的结构的列表管理字段之外，还有一些其他字段用于管理结构并确保它们在不需要时被删除：

In addition to the list management fields of the net_device structure discussed earlier, a few other fields are used to manage structures and make sure they are removed when they are not needed:

我们在第一章中看到网络代码大量使用了函数指针。数据 net_device结构包括其中相当多的部分。此类功能主要用于：

We saw in Chapter 1 that the networking code makes heavy use of function pointers . The net_device data structure includes quite a few of them. Such functions are used mainly to:

前面几节在描述用于完成特定任务的字段时已经介绍了一些函数指针。以下是通用的：

A few function pointers were already introduced in the previous sections when describing the fields used to accomplish a specific task. Here are the generic ones:

大多数网络功能在初始化时（在启动时或模块加载时）都会在/proc中注册一个或多个文件。当用户读取该文件时，它会导致内核间接运行一组返回某种输出的内核函数。网络代码注册的文件位于/proc/net中。

Most networking features register one or more files in /proc when they get initialized, either at boot time or at module load time. When a user reads the file, it causes the kernel to indirectly run a set of kernel functions that return some kind of output. The files registered by the networking code are located in /proc/net.

/proc中的目录可以使用 proc_mkdir. /proc/net中的文件可以使用 和 进行注册和注销proc_net_fops_create，proc_net_remove在include/linux/proc_fs.h中定义。这两个例程是通用 APIcreate_proc_entry和remove_proc_entry. 特别是，proc_net_fops_create负责创建文件（使用proc_net_create）并初始化其文件操作处理程序。让我们看一个例子。

Directories in /proc can be created with proc_mkdir. Files in /proc/net can be registered and unregistered with proc_net_fops_create and proc_net_remove, defined in include/linux/proc_fs.h. These two routines are wrappers around the generic APIs create_proc_entry and remove_proc_entry. In particular, proc_net_fops_create takes care of creating the file (with proc_net_create) and initializing its file operation handlers. Let's look at an example.

这是 ARP 协议在/proc/net中注册其arp 文件的方式：

This is how the ARP protocol registers its arp file in /proc/net:

静态结构文件操作 arp_seq_fops = {
    .owner = THIS_MODULE，
    .open = arp_seq_open,
    .read = seq_read,
    .llseek = seq_lseek,
    .release = seq_release_private,
};

静态 int _ _init arp_proc_init(void)
{
    if (!proc_net_fops_create("arp", S_IRUGO, &arp_seq_fops))
        返回-ENOMEM；
    返回0；
}

static struct file_operations arp_seq_fops = {
    .owner      = THIS_MODULE,
    .open       = arp_seq_open,
    .read       = seq_read,
    .llseek     = seq_lseek,
    .release    = seq_release_private,
};

static int _ _init arp_proc_init(void)
{
    if (!proc_net_fops_create("arp", S_IRUGO, &arp_seq_fops))
        return -ENOMEM;
    return 0;
}

这三个输入参数proc_net_fops_create告诉你文件名是arp，它必须只分配读权限，文件操作处理程序集是arp_seq_ops。当用户读取文件时，数据结构的使用file_operations允许procfs将数据以块的形式返回给用户。当数据由相同类型的对象集合组成时，这非常有用。例如，ARP 缓存一次返回一项，路由表一次返回一条路由等。

The three input parameters to proc_net_fops_create tell you that the filename is arp, it must be assigned read permission only, and the set of file operation handlers is arp_seq_ops. When a user reads the file, the use of the file_operations data structure allows procfs to return data to the user in chunks. This is useful when the data consists of a collection of objects of the same type. For example, the ARP cache is returned one entry at a time, the routing table is returned one route at a time, etc.

open被初始化的例程（arp_seq_open在前面的示例中）进行了另一个重要的初始化：它注册了一个函数指针数组，其中包含procfs用于遍历要返回给用户的数据的所有例程：一个例程用于启动转储，另一个用于推进一项项目，另一个用于转储一项项目。这些例程在内部负责保存必要的上下文信息（在本例中，已转储了多少 ARP 缓存），以记住转储所在的位置并从正确的位置恢复它。

The routine to which open is initialized (arp_seq_open in the previous example) makes another important initialization: it registers an array of function pointers that includes all the routines procfs uses to walk through the data that is to be returned to the user: one routine to start the dump, another to advance one item, and another one to dump one item. Those routines internally take care of saving the necessary context information (in this example, how much of the ARP cache has been dumped already) needed to remember what point the dump is at and to resume it from the right position.

静态结构 seq_operations arp_seq_ops = {
    .start=clip_seq_start，
    .next = neigh_seq_next,
    .stop = neigh_seq_stop，
    .show = Clip_seq_show,
};

static int arp_seq_open(struct inode *inode, struct file *file)
{
    ...
    rc = seq_open(文件, &arp_seq_ops);
    ...
}

static struct seq_operations arp_seq_ops = {
    .start   = clip_seq_start,
    .next    = neigh_seq_next,
    .stop    = neigh_seq_stop,
    .show    = clip_seq_show,
};

static int arp_seq_open(struct inode *inode, struct file *file)
{
    ...
    rc = seq_open(file, &arp_seq_ops);
    ...
}

用户看到的/proc/sys下的文件实际上是一个内核变量。对于每个变量，内核可以定义：

What the user sees as a file somewhere under /proc/sys is actually a kernel variable. For each variable, the kernel can define:

/proc/sys中导出的变量内容可以通过访问关联文件（前提是您具有必要的权限）来读取或写入，或者更直接地使用sysctl系统调用。

The content of the variables exported in /proc/sys can be read or written by accessing the associated file (provided that you have the necessary permissions), or more directly with the sysctl system call.

一些目录和文件是在启动时静态定义的；其他的在运行时添加。导致运行时创建目录或文件的事件示例包括：

Some directories and files are defined statically at boot time; others are added at runtime. Examples of events that lead to the runtime creation of directories or files are:

/proc/sys中的文件和目录都是用结构体定义的ctl_table。结构体通过kernel/sysctl.c中定义的和函数ctl_table进行注册和注销。register_sysctl_tableunregister_sysctl_table

Both files and directories in /proc/sys are defined with ctl_table structures. ctl_table structures are registered and unregistered with the register_sysctl_table and unregister_sysctl_table functions, defined in kernel/sysctl.c.

以下是 的关键字段ctl_data：

Here are the key fields of ctl_data:

根据与文件关联的变量类型，proc_handler并strategy 进行不同的初始化。例如，proc_dointvec是proc_handler当内核变量由一个或多个整数值组成时要使用的例程。表 3-1和3-2分别列出了一些可用于初始化proc_handler和 的例程strategy。所有例程均在kernel/sysctl.c中定义并进行了详细注释。

Depending on what kind of variable is associated with a file, proc_handler and strategy are initialized differently. For example, proc_dointvec is the proc_handler routine to use when the kernel variable consists of one or more integer values. Tables 3-1 and 3-2 list some of the routines that can be used to initialize proc_handler and strategy, respectively. All routines are defined and well commented in kernel/sysctl.c.

strategy将orproc_handler函数初始化为一个例程（该例程是表 3-1或3-2中例程之一的包装器）的情况并不罕见。包装器可能需要添加某种逻辑或健全性检查，这取决于关联的内核变量的含义。下一节中有一个示例。

It is not uncommon for a strategy or proc_handler function to be initialized to a routine that is a wrapper around one of the routines in Tables 3-1 or 3-2. The wrapper may be necessary to add some kind of logic or sanity check that depends on the meaning of the associated kernel variable. An example is in the next section.

每当我们查看procfs接口来配置本书中介绍的任何功能时， proc_handler为了简单起见，我都会引用该函数。

Anytime we look at the procfs interface for the configuration of any of the features covered in this book, I will always refer to the proc_handler function for simplicity.

  {
      .ctl_name = NET_IPV4_CONF_FORWARDING,
      .procname = "转发",
      .data = &ipv4_devconf.forwarding,
      .maxlen = sizeof(int),
      .模式=0644，
      .proc_handler = &devinet_sysctl_forward,
  }

  {
      .ctl_name      = NET_IPV4_CONF_FORWARDING,
      .procname      = "forwarding",
      .data          = &ipv4_devconf.forwarding,
      .maxlen        = sizeof(int),
      .mode          = 0644,
      .proc_handler  = &devinet_sysctl_forward,
  }

  {
      .ctl_name = CTL_NET,
      .procname =“网络”，
      .模式=0555，
      .child = 网络表，
  }

  {
      .ctl_name    = CTL_NET,
      .procname    = "net",
      .mode        = 0555,
      .child       = net_table,
  }

在 /proc/sys 中注册文件

Registering a file in /proc/sys

我们看到文件可以分别使用 和 注册到/ proc/sys 和从/proc/sys注销。注册函数在源代码中有详细记录，需要两个输入参数：register_sysctl_tableunregister_sysctl_table

We saw that a file can be registered to and unregistered from /proc/sys with register_sysctl_table and unregister_sysctl_table, respectively. The registration function, well documented in the source code, requires two input parameters:

• ctl_table指向实例的指针

• A pointer to a ctl_table instance

• 一个标志，指示将新元素放置在ctl_table位于同一目录的实例列表中的位置：在头部 (1) 或在尾部 (0)

• A flag that tells where to put the new element in the list of ctl_table instances located in the same directory: at the head (1) or at the tail (0)

请注意，输入不包括对/proc/sys文件系统中添加输入register_sysctl_table 的位置的引用。原因是所有插入都是在 /proc/sys目录中进行的。如果要将文件注册到/proc/sys 的子目录中，则需要通过构建树（通过与字段链接的多个实例）来提供完整路径，并将其传递给 代表该文件根的实例。你建造的树。当树的任何节点尚不存在时，就会创建它们。ctl_tablectl_tablechildregister_sysctl_tablectl_table

Note that the input to register_sysctl_table does not include a reference to the location in the /proc/sys filesystem where the input ctl_table is added. The reason is that all insertions are made into the /proc/sys directory. If you wanted to register a file into a subdirectory of /proc/sys, you would need to provide the full path by building a tree (by means of multiple ctl_table instances linked with the child field) and pass to register_sysctl_table the ctl_table instance that represents the root of the tree you have built. When any of the nodes of the tree do not exist already, they are created.

让我们举两个例子，从一个更简单的开始。drivers/scsi/scsi_sysctl.c中的这段代码 显示了如何定义文件 logging_level并将其放置在/proc/sys/dev/scsi/目录中：

Let's take two examples, starting with a simpler one. This piece of code from drivers/scsi/scsi_sysctl.c shows how the file logging_level is defined and placed in the /proc/sys/dev/scsi/ directory:

静态 ctl_table scsi_table[] = {
    { .ctl_name = DEV_SCSI_LOGGING_LEVEL,
      .procname = "logging_level",
      .data = &scsi_logging_level,
      .maxlen = sizeof(scsi_logging_level),
      .模式=0644，
      .proc_handler = &proc_dointvec },
    { }
};

静态 ctl_table scsi_dir_table[] = {
    { .ctl_name = DEV_SCSI,
      .procname =“scsi”，
      .模式=0555，
      .child = scsi_table },
    { }
};

静态 ctl_table scsi_root_table[] = {
    { .ctl_name = CTL_DEV,
      .procname = "dev",
      .模式=0555，
      .child = scsi_dir_table },
    { }
};

int _ _init scsi_init_sysctl(void)
{
    scsi_table_header = register_sysctl_table(scsi_root_table, 1) :
}

static ctl_table scsi_table[] = {
    { .ctl_name     = DEV_SCSI_LOGGING_LEVEL,
      .procname     = "logging_level",
      .data         = &scsi_logging_level,
      .maxlen       = sizeof(scsi_logging_level),
      .mode         = 0644,
      .proc_handler = &proc_dointvec },
    { }
};

static ctl_table scsi_dir_table[] = {
    { .ctl_name    = DEV_SCSI,
      .procname    = "scsi",
      .mode        = 0555,
      .child       = scsi_table },
    { }
};

static ctl_table scsi_root_table[] = {
    { .ctl_name    = CTL_DEV,
      .procname    = "dev",
      .mode        = 0555,
      .child       = scsi_dir_table },
    { }
};

int _ _init scsi_init_sysctl(void)
{
    scsi_table_header = register_sysctl_table(scsi_root_table, 1) :
}

请注意， register_sysctl_tablepass 是代码中定义的树scsi_root_table的根 。结果如图3-1ctl_table所示。

Note that register_sysctl_table is passed scsi_root_table, which is the root of the ctl_table tree defined in the code. The result is shown in Figure 3-1.

图 3-1。注册 /proc/sys/dev/scsi/logging_level 文件

Figure 3-1. Registration of the /proc/sys/dev/scsi/logging_level file

另请注意，如果稍后您想将另一个文件添加到同一目录（例如 abc ），则需要定义一棵类似的树（即dev和scsi目录的两个相同ctl_table实例 ，以及新文件的一个新实例）abc）。ctl_table

Note also that if later you wanted to add another file to the same directory—say, abc—you would need to define a similar tree (i.e., the same two ctl_table instances for the dev and scsi directories, plus one new ctl_table instance for the new file abc).

为了简化向现有目录添加新文件的过程，开发人员有时会定义一个模板，并在每次将新文件添加到同一目录时重复使用该模板。使用模板的好处是，ctl_table用于导航目录的实例（例如，scsi_root_table在scsi_dir_table前面的示例中）只需要初始化一次：此后，每次添加新文件时，您将仅初始化叶节点（即真实的文件）。例如，请参阅net/core/neighbour.c中的相邻子系统如何定义neigh_sysctl_template和使用它（另请参阅第 29 章）。neigh_sysctl_register

What developers sometimes do to simplify the addition of new files to an already existing directory is to define a template and reuse it any time a new file is to be added to the same directory. The good part about using templates is that the ctl_table instances that are used to navigate the directories (e.g., scsi_root_table and scsi_dir_table in the previous example) need to be initialized only once: after that, every time you add a new file you will initialize only the leaf nodes (i.e., the real files). See, for example, how the neighboring subsystem defines neigh_sysctl_template and uses it with neigh_sysctl_register in net/core/neighbour.c (see also Chapter 29).

核心网络文件和目录

Core networking files and directories

图 3-2显示了/proc/sys中网络代码使用的主要目录。对于每个文件，它都会告诉您在哪一章描述了其文件。

Figure 3-2 shows the main directories used by the networking code in /proc/sys. For each one, it tells you in what chapter its files are described.

图 3-2。/proc/sys/net 中的核心目录

Figure 3-2. Core directories in /proc/sys/net

根据我们在上一节中看到的内容，让我们看看以net为根的树是如何在启动时定义和注册的。

Let's see, based on what we saw in the previous section, how the tree rooted in net is defined and registered at boot time.

对于图 3-2中的每个目录以及这些目录中的每个文件，都有一个 ctl_table. 图 3-3显示了图 3-2ctl_table中大多数目录的实例的定义位置以及子父关系。为了使该图更具可读性，并未包含所有目录。

For each directory in Figure 3-2, and for each file in those directories, there is an instance of ctl_table. Figure 3-3 shows where the ctl_table instances of most of the directories in Figure 3-2 are defined, and what the child-parent relationships are. Not all directories have been included to make the figure more readable.

图 3-3中的三个框显示了三个初始化示例 ctl_table。注意：

The three boxes in Figure 3-3 show three examples of ctl_table initializations. Note that:

• netdev_max_backlog文件被分配了一个 例程，但不是一个例程。因为是一个整数，所以用户的输入是用 读取的。proc_handlerstrategynetdev_max_backlogproc_dointvec

• The netdev_max_backlog file is assigned a proc_handler routine but not a strategy routine. Because netdev_max_backlog is an integer, the input from the user is read with proc_dointvec.

• min_delay文件被分配了 proc_handler和strategy例程。由于内核变量ip_rt_min_delay以秒为单位表示，jiffies而用户输入和输出以秒为单位，因此这两个例程负责将秒转换为jiffies。

• The min_delay file is assigned both the proc_handler and strategy routines. Because the kernel variable ip_rt_min_delay is expressed in jiffies but the user input and output are in seconds, the two routines take care of converting seconds to jiffies.

• ip_local_port_range文件是一个有趣的例子。它用于允许用户配置一个范围，定义为两个值。该范围必须遵守最小值和最大值。因此， 所选的strategy和proc_handler例程能够管理整数值数组（本例中为两个）。这些值extra1和extra2表示范围，用于确保用户的输入遵循该范围。

• The ip_local_port_range file is an interesting case. It is used to allow the user to configure a range, defined as two values. The range must respect a minimum and a maximum value. Therefore, the strategy and proc_handler routines selected are able to manage an array of integer values (two of them in this case). These values, extra1 and extra2, express the range and are used to make sure that the input from the user respects it.